Subsystem controllers are ubiquitous components of modern computer systems, peripheral devices within computer systems, and other electronic devices. The term “subsystem controller” generally refers to a subcomponent of a more complex electronic system, such as a computer, that comprises logic circuits, a programmable logic device, and a general-purpose micro-controller that executes a number of software routines. A subsystem controller is generally dedicated to one or a small number of specific control tasks. For example, the control of LED and LCD display devices incorporated in a front panel display of a computer system is generally carried out by one or more subsystem controllers. Use of subsystem controllers may offload computationally intensive and time-intensive tasks from the main processor or processors of computer systems, and may significantly decrease data traffic on critical busses of the computer system that are bottlenecks for data movement within the computer system.
Within a subsystem controller, control functionality is partitioned between logic circuits, including one or more programmable logic arrays (“PLAs”) or programmable logic devices (“PLDs”), and software routines stored in an electronic memory and executed by a micro-controller. FIG. 1 graphically illustrates a continuum of possible partitionings of functionality between hardware and software. In general, the control functionality of a subsystem controller can be entirely implemented in hardware, for example as an application specific integrated circuit (“ASIC”), as indicated in FIG. 1 by the ASIC and logic circuitry 102 at the left end of a line 104 representing a continuum of possible hardware/software partitionings within a subsystem controller. On the other hand, the control functionality within a subsystem controller may also be entirely implemented as software routines running on a micro-controller, as indicated in FIG. 1 by the micro-processor 106 at the right side of the continuum. Normally, control functionality is partitioned between hardware and software, as indicated by the subsystem controller 108 positioned towards the center of the continuum. For any specific subsystem controller, a decision is normally made as to the partitioning, and appropriate components are selected and together integrated on a printed circuit board (“PCB”).
Once the partitioning of control functionality between hardware and software has been determined and the components selected and integrated together on a PCB, the partitioning is fixed, as indicated in FIG. 1 by the arrow 110 pointing to a particular partitioning between hardware and software. In order to change a partitioning of functionality, the logic circuits need to be redesigned and re-implemented, different logic may need to be programmed into a programmable logic device, and different software routines may need to be rewritten for execution on the micro-controller. Such re-implementation may require erasing and burning in new or revised code into a read-only memory, replacement of logic circuits with new logic circuits, and, possibly, replacing major components of the subsystem controller. In general, therefore, once designed and implemented, the control functionality embedded within subsystem controllers cannot be economically repartitioned between hardware and software, nor can the subsystem controller be easily re-tasked, or reprogrammed, for new applications.
A hardware-only implementation of the control functionality of a subsystem controller, represented by the left-hand side of the continuum in FIG. 1, may operate far more efficiently than a hardware and software, or software-only implementation. In general, dedicated circuitry is faster and may be more power-efficient than software routines fetched from a memory device into a general micro-controller and executed by the micro-controller. However, hardware-only implementations are extremely specific for a given application. Moreover, when the control tasks are complex, the design effort required for a hardware device may be formidable, and the circuitry required may be too large to be implemented by programming a single programmable logic device. On the other hand, software-only implementations are easily directed towards a variety of different applications by creating and loading different software routines in system controllers. Software routines are often easier to implement and easier to test and debug than hardware implementations. However, for low-level control of electronic devices, software only running on a general microprocessor may be quite inefficient, requiring extensive polling of various signal line and register states and tedious attention to the time sequence of state changes within one or more electronic devices. Furthermore, the electrical interface to micro-controllers may be largely standardized and therefore rather inflexible. For these reasons, compromise hardware and software implementations, as depicted in FIG. 1 by the subsystem controller 108 towards the center of the continuum 104, are generally selected. The low-level tasks for which hardware implementations are most efficient and particularly well-suited are implemented in logic circuits and programmable logic devices, and higher-level, more complex, decision-based logic is implemented in software routines. While compromise hardware and software solutions provide a certain amount of flexibility, in that different software routines may be loaded and executed by the micro-controller, the compromise hardware and software solutions are nonetheless very specifically tailored towards particular electrical interfaces and types of control functionalities.
The development costs for developing a subsystem controller for a specific application may be relatively high when compared to the volume of production of the subsystem controller. The development costs for the subsystem controller include the costs for designing and for implementing logic circuitry, programming programmable logic devices, and developing software routines, but also includes significant expense and time in testing the design and implementation of the subsystem controller and for insuring quality and reliability of the subsystem controller during the manufacturing process. The cost of quality control during the manufacturing process is related to the number of different components that must be integrated together and interconnected within the subsystem controller. When problems are identified after design and manufacture, fixes may require costly redesign, re-implementation, and retesting of the subsystem controller.
The reliability and flexibility in application of subsystem controllers may often be related to the power consumption of a subsystem controller. Current subsystem controllers often employ system logic devices that use CMOS integrated low-power logic. Unfortunately, CMOS logic devices usually cannot be reprogrammed, and usually have limited memory capacity. Alternatively, current subsystem controllers may employ higher-power PLA devices which can be reprogrammed, but which also suffer memory size constraints.
Designers and manufacturers of subsystem controllers have therefore recognized a need for a versatile, low-cost, easily programmable, and energy-efficient subsystem controller device that can be programmed for a variety of different applications. A versatile subsystem controller device could be manufactured in high volume, thus decreasing design and implementation costs associated with low-volume single-application subsystem controllers. Furthermore, a versatile, easily programmable subsystem controller devices would allow for hardware standardization and decreased overall system design costs, while still allowing manufacturers to include proprietary control functionality within the subsystem controller device via proprietary programmable logic device programming and via proprietary software routines for execution on a micro-controller.